home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 1 / NetNews Offline Volume 1.iso / news / fido / ger / amiprog / 59 < prev    next >
Internet Message Format  |  1996-03-16  |  3KB
  1. From: Andreas_Kleinert@p10.f435.n2457.z2.fido.sub.org (Andreas Kleinert)
  2. Organization: COBOL Error #7. Computer is still ON.
  3. Path: f435.n2457.z2.fidonet.org!not-for-mail
  4. Newsgroups: fido.ger.amiprog
  5. Subject: Re: prioritaet (oder so)
  6. Message-ID: <MSGID_2=3A2457=2F435.10=40FidoNet_3032567d@fidonet.org>
  7. References: <37492458@p3.traveller.fido.de>
  8. Date: Wed, 16 Aug 1995 14:47:17 +0200
  9.  
  10. Hallo Peter,
  11.  
  12. In einer Nachricht vom 09 Aug 95 schrieb Peter Stegemann an mich:
  13.  
  14.  PS> Die Zeit die der Task mit Warten verplempert, muss man auch zur
  15.  PS> Rechenzeit zaehlen, schlieslich ist es auch verbrauchte Zeit, waehrend
  16.  PS> der andere Tasks nicht rechnen koennen.
  17.  
  18.  Richtig.
  19.  
  20.  PS> Das Feststellen, welcher Task wie lange dran war, ist der grosse
  21.  PS> Kniff... meine huebschen Theorien finden nur raus, wieviel Rechenzeit
  22.  PS> verbraucht wurde... Das koennen wir ja noch ausknobeln ;-)
  23.  
  24.  Vielleicht reicht das doch schon.
  25.  
  26.  Ich fass' es nochmal alles zusammen bzw. mach' ein paar weitere Vorschlaege:
  27.  
  28.    Ablauf:   - Start eines Basistasks mit Prioeriatet 0
  29.              - dieser startet einen Speedtest-Task mit Prioritaet 128,
  30.                der eine bestimmte Anzahl Schleifendurchlaeufe mit
  31.                einer einfachen Operation durchlaeuft.
  32.              - unser Basistask wartet mit Wait() auf eine Nachricht
  33.                des Speed-Tasks, in der dieser vor seiner Beendigung
  34.                mitteilt, wie lange er gebraucht hat (Sekunden)
  35.              - danach startet der Basistasks einen Runtimespeed-Task
  36.                mit Prioritaet -21 (vielleicht besser als -128),
  37.                der die gleiche Schleife durchlaeuft und vor und nach
  38.                jedem Durchlauf die Zeit (innerhalb Forbid()/Permit())
  39.                misst und diese Zeit an unseren Basis-Task schickt
  40.              - der Basis-Task wartet auf die Nachrichten des RTS-Tasks
  41.                und wertet diese bei jedem Erhalt dann grafisch aus:
  42.  
  43.                Braucht dieser z.B. zehnmal solange wie der Referenztask
  44.                (der angenommenerweise wohl 100% aller fuer Tasks zur
  45.                Verfuegung stehenden Rechenzeit erhalten) hat, stand
  46.                ihm nur ein Zehntel der CPU-Kapazitaet zur Verfuegung,
  47.                d.h. es waren nur 10% frei.
  48.  
  49.   Der Nachteil dieser Loesung - die aehnlich schon ein paarmal vorge-
  50.   schlagen wurde - ist, dass a) nur Taskzeiten einfliessen, also
  51.   z.B. keine Interrupts oder SuperVisorMode-Aktionen und b) die GUI-
  52.   Darstellung selbst Rechenzeit benoetigt. Desweiteren haengt c)
  53.   die Aktualierungsgeschwindigkeit der Anzeige natuerlich direkt mit
  54.   der freien Rechenzeit zusammen (beim abrupten Wechsel von 0 auf 20%
  55.   freie Rechenzeit werden eventuell die 0% gar nicht lange angezeigt,
  56.   sondern die vorherige Anzeige bleibt stehen und wir sind dann sofort
  57.   auf 20% Prozent - z.T. nur zu verhindern durch eine laengere Test-
  58.   schleife, was aber dann die Aktualitaet negativ beeinflusst).
  59.  
  60.   Viel mehr ist aber wohl ohne Hardware-Messungen nicht zu machen
  61.   (besonders nicht unter einem MT-OS).
  62.  
  63.  Bis dann, Andreas Kleinert (2:2457/435.10)          // Only Amiga makes it
  64.     EMail: Andreas_Kleinert@superview.ftn.sub.org  \X/  possible (since '88)
  65.  
  66.  * SuperView * SuperPlay * GameObjectDesign (G.O.D.) * and more *
  67.  
  68.